Secure NTP and XCO

For XCO, authenticated NTP can be used in two possible configurations:

XCO acts as a client to existing NTP infrastructure.
XCO runs its own NTP server. Steps for achieving this solution are provided below.

Also, there are many different visions for secure NTP that can range from authentication (at the low end) to leveraging the newest NTS (Network Time Secure) protocol that leverages public key cryptography via TLS (at the high end).

XCO is based on Ubuntu 18.04, and ntpsec from the upstream package maintainers does not allow for a comprehensive and well-supported usage of NTS. However, if this is an absolute requirement, you can achieve NTS support on XCO by manually compiling and deploying a recent version of ntpsec, but this is not a supported solution. This comes at the cost of not using the sanctioned Ubuntu packaging system for package updates, and this tradeoff may not be worth it within certain operational environments.

Enforcing authentication where XCO acts as a client to existing NTP infrastructure

If XCO is to act only as a client for authenticated NTP, then upstream NTP servers where XCO is pointed also need to support authenticated NTP. You can use public NTP servers for this purpose, such as those of the US National Institute of Standards and Technology (NIST). For more information, see the NIST website. The following is an excerpt from the site:

"The time messages will be authenticated using symmetric-key encryption in a manner that is fully compatible with the published NTP documentation. (Autokey and asymmetric key modes will not be used.) Each registered user will be assigned a unique encryption key, which will be linked to the IP address(es) of the user's system(s).

A registered user will be able to communicate with the authenticated server using this assigned encryption key or using a default key of 0, which is equivalent to disabling the encryption algorithm. Users who are not registered will not be able to connect to this server, but can use any of the other NIST servers, which will not be modified."

Enforcing authentication where XCO provides its own NTP server

Populate the /etc/ntp.keys file with a SHA1 symmetric key. This can easily be done with the following command (which uses the /etc/shadow file as input to produce the SHA1 hash, and this hash must be shared with all clients that need to authenticate):
```
echo "3 SHA1 `sha1sum /etc/shadow |cut -d ' ' -f 1`" > ntp.keys
```
Add the line ‘keys /etc/ntp.keys‘ to the /etc/ntp.conf file on XCO.
Share the SHA1 symmetric key from step 1 with any clients that are authorized to acquire NTP data from XCO. This could include the population of managed SLX devices for example.
Restart the NTP daemon on XCO, and verify that no start-up error for the ntpd process is logged to /var/log/syslog. For example, if the format of the /etc/ntp.keys file is invalid, then the following error is displayed.
```
Jun 12 20:38:36
        tpvm ntpd[16498]: authreadkeys: rejecting file '/etc/ntp.keys' after 1 error(s)
```
Note

From the perspective of NTP clients, if coming from a Linux system the /etc/ntp.keys file from the server configuration steps above should be available in the file system. For example, if this file is also placed at /etc/ntp.keys, then the step for acquiring NTP information from XCO is as follows:
```
# sntp -k /etc/ntp.keys <efa hostname>
```